I don't know how to get any more clear than the writeup in the PoC. Initially I had started to do some work to pull down a local oracle database and get it running from Docker but then it was correctly pointed out that there are hundreds of JDBC drivers available since 2007 and pinpointing exactly where the behavior manifests and when was genuinely beyond any rational scope, so our reaction is primarily based on the report itself, which clearly demonstrates failure.  As someone who has worked as a red teamer in the past, sometimes you DO NOT need to know exactly how or why an exploit works, as long as it works. In short, we know that with some JDBC drivers, you will be protected, which appears to be your case.  However, as the PoC exploit demonstrates, there are clearly some JDBC drivers where this isn't the case, and (Kevin/Jeremiah can freely correct my memory here) we made the decision to deprecate the Oracle Codec because we are unable to guarantee a safe harbor.  Part of the reasoning is that the Database Codecs we inherited, have practically zero unit tests, and because of the myriad of configurations involved with not just properly writing unit tests, but downloading and running them against a live database is so far beyond the time scope, AND then picking "the right" JDBC drivers, it's too much.  TO do it correctly we'd have to test against every JDBC driver in existence.  We could sample, but that would just create a cat/mouse game with future exploiters.  The algorithm would be, "find the one JDBC version where this doesn't work, then get a CVE# from Mitre against ESAPI.  This is as opposed to our Codecs for HTML/PercentCodecs for example, that have a universal standard declared:  we omit semicolons from our entity detection because modern browsers will render &amp even though by the spec, the correct behavior should only be & So we do sort of cater to browser vendors in THAT way for the codecs most people normally use.  Contrast:  3-6 popular browsers to test, vs 95 Oracle JDBC drivers. But this is universal for HTML/PercentCodecs, and potentially unique for every JDBC driver implementation.  Oracle in particular, can make changes whenever they want. So given the fact that we can't test to where we would feel safe, the decision was to deprecate the class, and if future people WANT or NEED the behavior of that Codec, they can snag it from a prior ESAPI commit and compile their own version.  The last part of the conversation back last July was this:  People shouldn't be relying on that OracleCodec in the first place.  To be frank:  it isn't doing anything special in the first place, the algorithm is "see a ', output ''" You don't need ESAPI for that. The original intent of the library before Kevin and I inherited it, was to be an emergency drop-in for a java web application that just got hacked, the idea was to use it to safeguard the app until things like PreparedStatements could be written.  The encoder functions turned out to have legs as it's still pretty uncommon for web frameworks to offer things like HTML escaping out of the box.  I'll put words in Kevin's mouth here, but I think we both agree that the chances that there are dozens if not hundreds of applications in the wild that implemented the OracleCodec that never got around to rewriting their queries into PreparedStatements, and at least on MY part, I'm absolutely fine with forcing the ecosystem to do an update.

I addition to Matt's reply (#888 (comment)), I just responded (#889 (reply in thread)) to your query in ESAPI GitHub Discussion #889 (which probably would have initially been a better initial spot for commenting on this.) I suggest if you need more details, you contact the author of https://github.com/uglory-gll/javasec/ESAPI.md as it could be that you using a different JDBC driver than the security researcher did in his tests. Other than that, I don't really know what to add that Matt hasn't already said. Lastly, if you wish to comment in the broader ESAPI context on this specific issue, please move those discussions to Discussion #889. Thanks.